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REMARKS 

No new matter has been added. Reconsideration and allowance of the current application 
are requested. 

Rejections under § 102 

Claims 1, 2, 5-7, 9-15, and 71-18 are rejected under section 102(e) as allegedly being 
anticipated by Schroeder et al. (US 2002/0099735, hereinafter "Schroeder"). 

The present invention is directed to native format tunneling, i.e. a technique for a 
messaging case in which both a sending application and a receiving application each employ a 
file format that is native to both applications, but different from a format used by the messaging 
exchange platform. See paragraph [0047]. This technique conserves large amounts of 
processing time and other resources that would otherwise have to be used to convert a message 
from one format to a central exchange format (i.e. XML), and then again converting the message 
from the message exchange format to the same or different format used by a receiving 
application. See paragraph [0046]. 

Accordingly, instead of so many conversions to the message being made, the claimed 
technique includes receiving a message from a sending application, wrapping the message in a 
markup language file envelope, and routing the markup language file envelope with the message 
through the exchange system. Since the message is to be received by a receiving application in 
the format that is native to the sending application, no conversion of the message is performed 
other than wrapping it into a markup language file envelope, which enables intelligent and 
seamless routing through the application integration system. 

Schroeder teaches a technique in which inbound data is translated or converted to an 
XML format, not once, but twice. Such translations, whether performed automatically or 
selectively, consume large amounts of resources to copy files to a directory, execute conversion 
processes on the data in the files, and other processes. See Schroeder, paragraphs [0038]-[0040]. 
Schroeder teaches receiving a data file, converting the data file into a "normalized XML file," 
and then converting the normalized XML file into an XML format "consistent with one of data 
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definition files associated with a Receiving Company's desired data format." 

Turning now to claim 1 , which recites "receiving a message from the sending application, 
the message having a message format used by the sending application; wrapping the message in 
a markup language file envelope. . .". Schroeder fails to teach or suggest wrapping a message in 
a markup language file envelope. Schroeder, on the other hand, teaches converting a message 
from its original format into a normalized XML file. 

Claim 1 further recites "routing the markup language file envelope with the message 
through the application integration system; unwrapping the message from the markup language 
file envelope; and transmitting the message according to the message format to the receiving 
application." (emphasis added). Schroeder fails to teach or suggest unwrapping a message from 
a markup language file envelope, and then transmitting the message according to its original, 
native format. Schroeder, on the other hand, teaches converting the normalized XML file into an 
XML format that is automatically selected or selected on-the-fly by a receiver. 

Thus, claim 1 is not anticipated by Schroeder, and an indication to that effect is 
courteously solicited. Claims 2, 5 and 6 are allowable over Schroeder at least for their 
dependence, directly or indirectly on an allowable base claim. 

Claim 7 recites a step, "if the file format used by the receiving application is substantially 
identical to a file format used by the sending application, wrapping the message in a markup 
language file envelope." These limitations in this step are clearly not taught or suggested by 
Schroeder. Schroeder neither teaches nor suggests the use of a markup language file envelope as 
recited; instead, Schroeder teaches converting a file into an XML file, i.e. the "normalized XML 
file." This conversion requires converting the message also into XML. 

Further, Schroeder neither teaches or nor suggests the limitation of the use of XML 
conditioned on "if the file format used by the receiving application is substantially identical to a 
file format used by the sending application." As discussed above, this is done in order to 
conserve processing and other resources, so that unnecessary and wasteful conversions from one 
file format to several other file formats are avoided. 

Thus, claim 7 is not anticipated by Schroeder, and an indication to that effect is 
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courteously solicited. Claims 9-14 are allowable over Schroeder at least for their dependence, 
directly or indirectly on an allowable base claim. 

Claim 15 recites "an inbound adapter connected with the sending application, and 
configured to determine at least one receiving application for receiving the message, determine a 
file format used by the receiving application, and if the file format used by the receiving 
application is substantially identical to a file format used by the sending application, wrap the 
message in a markup language file envelope according to a markup language format used by the 
application integration system." (emphasis added). As discussed above with respect to claims 7 
and 1, Schroeder does not teach the use of a markup language file envelope, nor as discussed 
with respect to claim 7, the condition of using the markup language file envelope based on if the 
file format used by the receiving application is substantially identical to a file format used by the 
sending application. 

Accordingly, claim 15 is not anticipated by Schroeder, and claims 17 and 18 are 
allowable over Schroeder at least for their dependence, directly or indirectly, on claim 15. 

Rejections under § 103 

Claims 3, 4, 8, and 16 are rejected under section 103(a) as allegedly being unpatentable 
over Schroeder as applied to claims 1, 7, and 15 above, and further in view of Erickson et al. 
(US 6,851,089, hereinafter "Erickson"). 

First, claims 3, 4, 8, and 16 derive patentability for their dependence, directly or 
indirectly, on an allowable base claim. 

Nevertheless, the rejection is arguably based on Erickson' s description of a wrapper 
serialization component for storage and retrieval of wrappers in XML. However, Erickson goes 
on to describe the use of wrapper serialization as a way to store and retrieve wrappers using a 
"wrapper builder application" which deserializes the wrapper to reproduce the objects the 
wrapper comprises. See Erickson col. 26, lines 21-29. Further, wrappers are generally created 
by a human author, and tailored to function on a specific format of semistructured information. 

Thus, the step of serializing data objects in order to wrap a message (which need not be 
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semistructured information) in a markup language file envelope, as recited by claim 3 is neither 
taught nor suggested by the combination of Erickson's wrapper serialization technique for 
storing wrappers and Schroeder's message conversion and exchange system. Thus, this rejection 
is also traversed, and a notice to that effect is respectfully requested. 
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CONCLUSION 



On the basis of the foregoing amendments, the pending claims are in condition for 
allowance. It is believed that all of the pending claims have been addressed in this paper. 
However, failure to address a specific rejection, issue or comment, does not signify agreement 
with or concession of that rejection, issue or comment. In addition, because the arguments made 
above are not intended to be exhaustive, there may be reasons for patentability of any or all 
pending claims (or other claims) that have not been expressed. Finally, nothing in this paper 
should be construed as an intent to concede any issue with regard to any claim, except as 
specifically stated in this paper. 

No fee is believed to be due, however the Commissioner is hereby authorized to charge 
any fees that may be due or credit any overpayment of same, to Deposit Account No. 50-03 1 1 , 
Reference No. 34874-062/2003P00267 US. If there are any questions regarding reply, the 
Examiner is encouraged to contact the undersigned at the telephone number provided below. 



Mintz, Levin, Cohn, Ferris, Glovsky and Popeo, P.C. 

9255 Towne Centre Drive, Suite 600 

San Diego, CA 92121 

Customer No. 64280 

Tel.: 858/320-3033 

Fax: 858/320-3001 



Respectfully submitted, 



Date: October 9, 2007 
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